P.B.5818 - Patentlaan 2 
2280 HV Rijswijk (ZH) 
S +31 70 340 2040 
TX 31651 epo nl 
FAX +31 70 340 3016 



Europaisches 
Patentamt 



Generaldireklron 1 



European 
Patent Office 



Office europ^en 
des brevets 



Directorate General 1 DifBction Generals 1 



Cabinet Hirsch 
34^ Rue de Bassano 
75008 Paris 
FR 



J 



Datum/Date 



23/02/04 



Zeichen/Ref./Ref. 

20538EP DAS4 MG 


Anmeldung NrVApplicatlon No./Demande n'^yPatent Nr ./Patent NoVBrevet n**. 
03290713.1 1243 


Anmelder/Applicant/Demandeur/Patentinhaber/Proprietor/Titulaire 
Dassault Svstemes S.A. 



Ubersendung von/Transmission of/Envoi de 

□ 



Antrag vom/Request dated/ Requete du 12/02/04 



□ 



Kopien bei Akteneinsicht nach Regel 94(3) EPU 
Copies in the case of inspection of files pursuant to Rule 94(3) EPC 
Copies en cas d'Inspection publique selon la regie 94(3) CBE 

Beglaubigung 

Certification 

Certification 



Prioritatsbeleg(e)/priority document(s)/document(s) de priorite R. 94(4) 



□ 
□ 
□ 
□ 



Ausfertigung(en) der Patenturkunde nach Regel 54(2) EPU 

Duplicate of the patent certificate pursuant to Rule 54(2) EPC 

Duplicata du certificat de brevet, selon la Regie 54(2) CBE 

Auszug aus dem Register nach Regel 92(3) EPU 
Extract from the register pursuant to Rule 92(3) EPC 
Extrait du registre selon la Regie 92(3) CBE 

Auskunft aus den Akten nach Regel 95 EPU 

Communication of information contained In the files pursuant to Rule 95 EPC 
Communication d' informations contenues dans la dossier selon la R^le 95 CBE 

Akteneinsicht nach Regel 94(2) EPU 
inspection of files pursuant to Rule 94(2) EPC 
Inspection publique selon la Regie 94(2) CBE 



EPA/EPO/OEB Form 1158 -08.94 



PERON L (TEL: 3632) 
Auslcunftsstelle/Informatlon office/Service dMnformatlon 



THIS PAGE BUNK (usPTO) 



Europaisches 
Patentamt 



European 
Patent Office 



Office europeen 
des brevets 



Bescheinigung Ceriificate 



Attestation 



Die angehefteten Unterla- 
gen stimmen mit der 
ursprunglich eingereichten 
Fassung der auf dem nach- 
sten Blatt bezeichneten 
europaischen Patentanmel- 
dung uberein. 



The attached documents Les documents fixes a 
are exact copies of the cette attestation sont 
European patent application conformes a la version 
described on the following Initialement deposee de 
page, as originally filed. la demande de brevet 

europeen specifiee a la 
page suivante. 



Patentanmeldung Nr. Patent application No. Demande de brevet n^ 

03290713. 1 



Der Prasident des Europaischen Patentamts; 
Im Auftrag 

For the President of the European Patent Office 
Le President de rofflce europeen des brevets 

P.O. 



R C van Dijl< 



EPA/EPO/OEB Form 1014.1 - 02.2000 7001014 



THIS PAGE BLANK (uspro) 




Europaisches 
Patentamt 



European 
Patent Office 



Office europten 
des brevets 



Anmeldung Nr: 

Application no.: 03290713.1 



Demande no: 



Anmeldetag: 

Date of filing: 20.03.03 
Date de d^pot: 



Anmelder/Appl 1cant( s)/Demandeur( s): 

Dassault Systemes S.A. 
9, Qua! Marcel Dassault, 
B.P. 310 
92156 Suresnes 
FRANCE 



Bezelchnung der Erf 1 ndung/Tl tl e of the 1 nventlon/Tl tre de 1' Invention: 
(Falls die Bezelchnung der Erflndung nicht angegeben 1st, slehe Beschrelbung. 
If no title Is shown please refer to the description. 
SI aucun titre n'est Indlqu^ se referer ft la description.) 

Server process for accessing data from various types of client processes 

In Anspruch genommene Prlorlat(en) / Priori ty( les) claimed /Pr1or1t6(s) 
revendl qu^e( s) 

Staat/Tag/Aktenzelchen/State/Date/Flle no./Pays/Date/Num^ro de d^pot: 



Internationale Patentklasslfl kati on/International Patent Classification/ 
Classification Internationale des brevets: 

606F9/46 

Am Anmeldetag benannte Vertragstaa ten/Contracting states designated at date of 
flllng/Etats contractants d^slgn^es lors du d^pot: 

AT BE BG CH CY CZ DE DK EE ES FX FR GB GR HU IE IT LU MC NL 
PT SE SI SK TR LI 



03290713. 1 
EPA/EPO/OEB Form 1014.2 - 01.2000 



7001014 



2 



THIS PAGE BLAf^K (uspto) 



1 



SERVER PROCESS FOR ACCESSING DATA FROM VARIOUS 
TYPES OF CLIENT PROCESSES 

5 The invention relates to the field of computer systems, and more specifically to 

server processes for allowing client processes to access data. 

There exists a need, in computer systems, to allow client processes to access 
data through a server process. This need arises for instance for servers offering 
information through the Internet to clients issuing queries in the html language. The 

1 0 server process hosted on the server needs to allow the client processes to access the 
requested information. Figure 1 is a schematic view of the architecture of such a 
system. The server process 2 comprises data 4, to which access should be provided. 
The server process further comprises an application 6 and a motor 8. The motor may 
be one of several products sold on the market, such as provided under the trademark 

15 PHP by Apache Software Foundation, under the trademark ASP by Microsoft or 
under the trademark JSP by Sun Microsystems . 

Figure 1 further shows two client processes 10 and 12; in a generic case, the 
server process is hosted by one or more server machines, while each of the client 
process is hosted by a separate client machine. The client processes is a Web browser 

20 such the ones provided by Netscape Corp. under the trademark Navigator or by 
Microsoft Corp. under the trademark Internet Explorer. The client processes and the 
server process are connected, e.g. through a network using a protocol of the IP 
family. Client processes 10 and 12 communicate with the motor of the server process 
using html, dynamic html or other additional technologies such as activeX, Java 

25 applets, JavaScript (Trademark of Sun Microsystems, supplied by Web Browser such 
as Microsoft Internet Explorer, Netscape Navigator). For the sake of simplicity, html 
is taken as a generic example in further discussion in the specification. 

The application 6 uses the same language for communicating with the motor. It 
may further use functions provided by the motor. 

30 The operation of the system is the following. Client processes 10, 12 issue 

requests to the motor 8, in the html language. Requests from the various clients are 
passed by the motor 8 to the application 6, in the html language and possibly using 
additional functions specific to the motor. Requests from the motor are processed by 
the application 6, which accesses data 4 when necessary. Responses from the 

35 application are provided to the motor in the html language and are forwarded to 
client process. 

In this type of architecture, applications are hardly portable and are dedicated 
to html clients. Motors such as the ones listed above provide additional functions or 
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libraries for facilitatmg development of applicatiom; however the bas.s for 
communication between applications and the motor remains htm.. Ihus. app cat.ons 
are ncoessaxily speciftc to html clients and arc not easily adapted to other types of 
clients. Thus, languages such as JSP. ASP or, PHP are html-based and any 
5 application written in these languages will include html parts. 

The need to allow access to data through a server process ts also presen for 
clients outer than hmtl dients. Dassault Systemes sells under the tradetnark CATIA a 
CAD p.x,duet; a schematic view of the architecture of this product ,s shown m figure 
2 in one example of a possible implementation of the product for two chen. 
1 0 p'roeesses 20 and 22. Figure 2 shows a machine 24, hosting data 26 as well as one 
C A^ A process 28, 30 for each of the client processes 20, 22. Each CATIA process 
contains'a copy of an appHcation 32, 34, as well as a motor 36, 38^T^ CATIA ne 
of products ,s designed to allow an application developed under CATIA s.an<h>rds to 
opLe with one of several motors; each motor is designed for one tjT,e of chen. 
15 pLess, e.g. Unix chents or Windows (trademark) dients. This makes tt possible to 
Z the sale appheation for serving client processes running d.fferen, opcra^g 
systems. More specifically, as represented on figure 2, one copy of the same 
aoDlication is used for serving each cUent process. 

The appHcation is thus portable, inasmuch as it may be used for various wes 
20 of clients running on various types of machines. As shown in figure 2. one CATIA 
process ,s used for each cl.ent process, even though *e same data may be accessed 
by both processes. Each CATIA process 28. 30 would typically create tts own copy 
of .he data and care for the update of the data 26 according to amendments o the 
data made by cl.ent processes. This may be limit the r^-«me shartng of data 
25 between U,e client processes, inasmuch as data locally amended by 

given CATIA process 28 may not be accessed by other client processes 22 unhl the 
!pplieafion 32 in the given ptoeess 28 manages the update of data 26. In the example 
of figure 2, both CATIA processes 28, 30 are hosted on the same machme 24 as the 
data^ne could also use separate machines; there would still be one CATIA process 

30 for each client. . ^„„„, 

Thus there is a need for a computer system, which makes it possible to allow 
various clients to simply access data and in which applications would still be portable 
from one type of clients to the other. 

Accordhig to one embodiment of the invention, there is provided a computer 
35 system for allowing at least two chent processes to access data through a server 
process compnsmg an appHcation and a motor. The motor is adapted to receive 
requests in a first language from one of client processes and issue responses m the 
first language to said one of client processes; the motor is adapted to commumcate 
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with the application in a second language distinct from the first language, the second 
language being an object-oriented language, with objects having properties and 
associated with events. The application is adapted to instantiate objects, to evaluate 
properties of instantiated objects based on data and to react to events. The motor is 
5 adapted to issue responses in the first language to said one of client processes 
according to the objects instantiated by the application and to their properties. The 
motor is adapted to provide updated properties and events to tlie application in the 
second language according to requests received in the first language from said one of 
client processes. 
10 Preferably, the motor is further adapted 

to receive requests in the first language from another client process and issue 
responses in the first language to said another client process, 

to issue responses in the first language to said another client process according to 

the objects instantiated by the application and to their properties; 
15 - the motor is adapted to provide updated properties and events to the application 

in the second language according to requests received in the first language from 

said another client process. 
It is also possible to provide that 

the motor is further adapted to receive requests in a third language from another 
20 client process and issue responses in the third language to said another client 

process, the third language being different from the first language and distinct 

from the second language; 

the motor is adapted to issue responses in the third language to said another client 
process according to the objects instantiated by the application and to their 
25 properties; 

the motor is adapted to provide updated properties and events to the application 
in the second language according to requests received in the third language from 
said another client process. 
In this case, the motor is provided with a first renderer for communicating with 
30 said client process in said first language and with a second renderer for 
communicating with said another client process in said third language. 

In another embodiment, a client process communicates with the motor of the 
server process through an application process. The application process comprises: 
a second motor adapted to communicate with tlie client process; 
35 - a second application adapted to communicate with the second motor; and 

a client interface adapted to communicate with the motor in the first language and 
adapted to communicate with the second application and / or with the second 
motor. 
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Preferably, the first language includes html. 

The invention also proposes, in another enibodiment, a motor for servmg 
clients processes and allowing the dicnts processes to access to data managed by an 
application; the motor comprises: 

- a first renderer adapted to receive requests from a chcnt process m a first 

language and to issue responses in the first language; 
. a second renderer adapted to receive requests from a chent process m a third 
language and to issue responses m the third language, the third language bemg 
different from the first language; _ 
an applicafion interface adapted to issue and receive messages m a second 
language, distmct from the first language and fi-om the third language, the second 
language being an object-oriented language, with objects having properties and 
associated with events. , i ^ * 

The motor is adapted to issue responses in ti,e first language through the first 
,5 renderer and responses in the mird language through a>e second renderer accordmg 
to the objects and properties contained in the messages rece.ved on the appheat.on 
interface; the motor is adapted to issue through the application '"'"f™-^- 
with updated properties and events accordmg to requests reeved by the fi,.t and 

second renders. 
90 Again, the first language may include html. 

A computer system embodying the invention will now be described, by way of 
non-hmiting example, and in reference to the accompanying drawings, where : 

. . figure 1 is a schematic view of the architecture of a prior art server for html 

clients; 

25 - figure 2 is a schematic view ofthe architecture ofaCATIA system; 

figure 3 is a schematic view of the architecture of a system according to the 

invention, with similar client processes; 
- figure 4 is a schematic view of the architecture of a system according to the 

invention, with different client processes; 
30 - figure 5 is a schematic view of the architecture of another embodiment of a 

system according to the invention; 

figure 6 is a more detailed schematic view of a system according to the invention. 
The invention proposes a computer system for allowing at least two chent 
processes to access data through a server process. It allows data to be shared by the 
35 various client processes; in other words, the same data may be accessed at the same 
fime by various client processes. In addition, it makes it possible for the server 
process to provide data access to various types of clients. 
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Figure 3 is a schematic view of the architecture of a system according to the 
invention, in an embodiment w^ith similar chent processes. It shows the server 
process 50 as well as two client processes 52 and 54. Only two client processes are 
shown for the sake of simplicity. From the standpoint of physical implementation, 
5 the server process and the client processes may be running on separate machines; 
they could also be running on the same machine. This is not relevant to the operation 
of the invention, and physical implementation is not discussed in the rest of this 
specification. 

As shown in figure 3, server process 50 is used to access data 56. Server 
10 process 50 comprises an application 58 and a motor 60. Motor 60 is adapted to 
receive requests for one of client processes 52 and 54, in a jfirst language. Figure 3 
shows the communication links 62, 64 between the motor and the processes. In the 
example of client processes similar to the ones of figure 1, the first language would 
typically comprise html and related extensions. The motor is also adapted to issue 
15 responses to one or the other of the client processes, in the first language. In the 
example, processes 52 and 54 use the same language to commxinicate with motor 60 
- e.g. html and related technologies which is symbolised by the single dash on 
each of links 62, 64. 

The motor further communicates with the application, in a second language 

20 which is distinct from the first language, as represented on figure 3 by the double 
dash on communication link 66 between motor 60 and application 58. The second 
language is distinct from the first language, in that the syntax of the second language 
is independent from the one of the first language. Notably, the second language does 
not use syntax elements from the first language. Thus, any change in the first 

25 language will not reflect in the second language. The fact that the second language is 
distinct from the first language makes it possible to develop the application 
independently of the processes which are served by the motor. As discussed below in 
reference to figures 4 and 5, one may serve different tj^es of client processes, 
without having to develop again the application for this type of client process or 

30 adapt the application to the client process. 

This is a major advantage compared to the prior art solution discussed in 
reference to figure 1. For instance, if an application is developed in JSP or ASP, it 
will necessarily include html parts and will solely be adapted to serve clients which 
are html browsers. If the same data needs to be accessed by another type of client 

35 process, the application needs to be developed anew, with a different motor. 

In the example of figure 3, the second language is also an object-oriented 
language, with objects having properties and being associated with events. Apart 
fi:-om the advantages inherent to object languages, the choice of an object-oriented 
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language makc= i. easier to provide a second language distinct Iron, the f s. 
language. Indeed, motor 60 will receive requests fron, one of client processes 52. 54 
in L Lt language; according to the content of this request, motor 60 w.U prov,d 
updated properties or events to appUca.ion 58, or que^ the applic.fon for proper, e 
a!d events. The application will then simply receive from the motor upda ed 
properties and / or events, or requests for objecfs properfes. .^--"'"S < *^ 
Lquests, the application will instantiate objects, evaluate propert.es °f ^ 
objects based on data and / or react to events. The updated properttes. or the reactron 
to the events is fonvarded by .l>e application to the motor. The motor then provtdes 
an answer, in the first language, to the relevant process or processes, based on the 
mfoimation provided by the application. 

Th.s aLunts to separating, between application 58 and motor 60, the vanous 
aspects of the service provided by the server process to the client processes. FeaU.es 
spcfic to the type Client being served would be handled by the motor and would n^t 
be passed to the application. This may for instance ^^^'^'^ 
offered by the service. Data and behaviour would typically handled by the 
application. Figure 4 is a schematic view of the architecture of a system according to 
the invention, with different chent processes. Figure 4 rs similar to figure.3 ^d the 
• same reference numbers are used wherever possible; figure 4 shows, -^ead of chen 
process 54, a client process 68 of a type different from client process 52. Ghent 
process 68 commumcates with motor 60 over communication link 70. As symbohsed 
by the treble dash on Hnk 70, cUent process 68 uses a third language to communicate 
with motor 60, the thxrd language being different from the '~; J^^ 
instance, the first language could be html. The third language could be adapted to 
Windows (trademark) clients or to Unix clients without requiring the use of a Web 
browser adapted to understand html. It could also be some proprietary language, as 
discussed below. The third language is different from the first language, but may 
have similarities or may have some items common with the first language. The th,rd 
language is disfinct from the second language, for the reasons given m reference to 
figure 3 as regards the distinction between the first and second languages. 

Motor 60 of figure 4 has two different renderers 72 and 74. A renderer 72 or 74 
is adapted to receive requests in a language - the first or third language - and to issue 
responses in the respective language to the relevant client. Due to the presence of 
separate renderers, functions of the motor 60 which are independent from ±e 
language used for addressing the client processes - e.g. communication with the 
application, queuing requests from client processes, etc. - need not be replicated for 
serving different client processes. The renderer translates cUents requests and 
generates responses, for one, or a set of client language, thus it contains everything 
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specific in the motor to this or this set of client language. Figure 4 further shows the 
application interface 75, which is used by the motor for receiving and issuing 
messages in the second language. 

Comparison of figures 3 and 4 shows that there is no need in the exemplified 
5 architecture to adapt the application for serving client processes of different types. 
Simply by providing an additional renderer in the motor, the example of figure 4 
makes it possible to serve different client processes. This does not imply re- 
developing the application. Comparison of figures 4 and 2 shows that the 
exemplified architecture makes it possible for different client processes to address 
10 the same data, in real time. There is no need in the application to manage a copy of 
the data. All client processes access the same data, which may be updated 
contemporaneously by the various client processes. 

Figure 5 a schematic view of the architecture of another embodiment of a 
system according to the invention. It shows that the architecture of figure 4 may also 
15 be used for allowing client processes to access data through application processes. 

In figure 5, server process 50 and client process 52 are identical to the 
corresponding elements of figure 4 and are not fiiUy discussed again. For the sake of 
explanation, application 58 is a product life cycle management application, e.g. of 
the type sold by Dassault Systemes under the trademark ENOVIA. The first renderer 
20 72 of the motor is an html renderer, and is adapted to be used by client process 52, 
which runs a Web browser. Figure 5 only shows one web client, but there could, be 
more tlian one. This makes it possible for a html client to access the data 56 through 
the application 58. In the example, the html chent may thus use the product life cycle 
management. 

25 Figure 5 further shows two client processes 76 and 78. For the sake of 

explanation, these processes are running on different platforms. Process 76 may be a 
Windows process and process 78 a Unix process. Client processes 76 and 78 do not 
access motor 60 directly, but through CATIA processes 80, respectively 82. Process 
80 comprises a Windows motor 84 adapted to communicate with the Windows client 

30 process 76, while process 82 comprises a Unix motor 86 adapted to communicate 
with the Unix client process 78. Each process 80, 82 further comprises a CATIA 
application 88, 90; the associated data are not represented. Both applications may be 
identical. Each CATIA process 80, 82 is further provided with a client interface 92, 
94 adapted to communicate with second renderer 74 of motor 60 in the third 

35 language, over communication link 96. The client interface 92, 94 communicates 
with its associated motor 84, 86 in the same language used between the application 
88, 90 and the motor 84, 86, thus CATIA in the example. 
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As in figure 2, each client process 76, 78 may access the CATIA application 
88 90 In addition, each client process may access the ENOVIA application 58 and 
use the corresponding data 56. There is no need to provide an additional environment 
for the client process (e.g. html) for allowing access to the ENOVIA application. For 
the user, the ENOVIA application is usable within the environment of his usual 
CATIA client. Access to either CATIA or ENOVIA application is transparent for 
client processes 76, 78; however, there is no need to provide the client processes 76, 
78 with separate accesses to the CATIA and ENOVIA applications. 

The example of figure 5 makes it possible to address various types of clients, 
as in the example of figure 4; in addition, it allows previously developed applications 
(such as the exemplified CATIA applications) to be re-used. The applications 88, 90 
do not need to be adapted: processes 80, 82 are simply provided with a client 
interface 92, 94 for addressing the motor 60. The same data 56 may be 
contemporaneously accessed by both client processes 76 and 78. 

Another advantage of the solution of figure 5 is that the motor 60 of the server 
process 50 may be provided with only one renderer 74 for addressing chent 
processes 76 and 78, even though these client processes are different. Indeed, motors 
84 and 86 already take into account the differences between client processes 76 and 
78, so that the same client interface 92, 94 may be used in the CATIA processes 80, 
82' The example of figure 5 capitalizes on existing motors to limit the need for new 
developments. 

Figure 6 is a more detailed schematic view of a system according to the 
invention. Figure 6 shows the example of a html dient. The client process 52 
contains a Web browser 100; a browser frame 102 is displayed to the client, using 
the server applications user interface 104, in html. The motor 60 in the server process 
60 contains the html renderer 72 and an abstraction layer 106. In reaction to user's 
input in the user interface 104, the Web browser 100 produces URLs fonvarded to 
the server process, e.g. on an http network such as the Internet. The URL is received 
by the html renderer 72 of the motor and is converted to notifications in the 
abstraction layer 106. This is represented on figure 6 by arrow 108. Abstraction layer 
106 passes to the application updated object properties or events, based on the 
received URL, or request for updated properties. This is represented on figure 6 by 
arrow 1 10. As discussed above, communication between the abstraction layer 106 of 
the motor and the application 58 does not include html elements. 

The application instantiates objects and provides properties to the abstraction 
layer 106, as represented by arrow 1 12 on figure 6. These are used in html renderer 
for providing an html page to the web browser, the page is displayed on the user 
interface 104, as represented by arrow 1 14 in figure 6. 
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Assume a sample user display contains a List of items, a text-area to enter a 
new value in the list and a button to validate the new value. From the point of view 
of the application, the content of the list of items is a set of data; the text-area is an 
object, the text being a property of the object; the button to validate is a second 
5 object, which is associated with an event when the user validate the button. 

The generated HTML page will contain a HTML table to display part of the list 
(e.g. items 1 to 20 of 200), with items as cells of this table. The header of the HTML 
table will contain a list header hyperlink to navigate to the next part of the list. The 
HTML page will also contain a HTML form with a button and a text input. The 
10 HTML page is generated by the motor, based on the items provided by the 
application and based on the current properties of the objects. The generated HTML 
page is provided to the client process, 

Wlien the user clicks on the list header hyperlink to display the next part of the 
list of items, the web browser, using a URL generated by the motor during the first 
15 HTML page generation, starts a new HTTP request. The request is passed to the 
motor; the motor then obtains from the application the next part of the list of items 
(e.g. items 21-40). The motor generates a new HTML page containing the next part 
of the list of items. The properties of the objects are not updated. 

Assume now that the user modifies the content of the text area to enter a new 
20 item in the list and then activates the button. The web browser starts a new HTTP 
request. The motor receives the request and identifies the modified content of the 
text-area and the activation of the button. The updated property of the text-area 
object is passed to the application, together with the event associated with the button. 
Note that this is fully independent of the HTML coding of the text-area and button in 
25 the user display. 

In response to the event, the application may read the modified property of the 
text object and amend accordingly the data to add a new item in the list. The 
application provides a new part of the list of items to the motor; the motor again 
generates a HTML page. 

30 

The example shows that the type of client process - HTML docs not 
influence the application, since all HTML dependent coding is carried out by the 
motor. 

Figure 6 evidences that the "look and feel" of the user interface is actually 
35 provided by the html rcndcrer 72, which creates htlml pages based on information 
provided by the abstraction layer. This ensures that applications using the motor will 
all provide user interfaces on the Web browser having the same "look and feel" to the 
end user. Developers working on applications need not care about the browser's user 
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interface, bu, n,ay co„ee„,r«e on .he actual appUeat o. The - » — 
makes it possible to change the "look and feel" of the mer tnterfaee, .s only 
Teces a y o change the renderer to change the user interface. For .nstartce. coK,urs. 
fonts other sinul. features of the user interface a« defined in the renderer. These 
Lay b *iged by amending .he renderer or providing a new renderer, w.thou. 
ILlg or'ehan^ing .he appUcalion itself Another way - 
interface is to provide different sets othunl static resources - CSS or .mages 
"rchanging the static resources changes the look of the user tntorface. 

""'--'■-"^'""rrZltced by the person skilled in the ar, using 

The invention may be reproaucea uy y , 

techniques known per se in the ar, of programming. As discussed above, the 
used for communication between dte motor and *e clien. processes .nay 
cZI html and related technologies. The language used — ea«o„ 
between the mo.or and the applicaUon processes in the example of figt^ 5 may bc^ 
proprietary language, similar to to language used for communtcalton w.thm fte 
"cess between the motor and the application. Tils proprietary language may 
Tmade of a se, of classes defined in .he Java l^guage. and an XML r3mn,ar. 

The inven.ion may be embodi«l in programs having routines for carryng out 
Ae various steps discussed in reference to the figures. 

™ e invLon is not iimi.ed to ,he examples and embodiment d.scussed m 
Inference to .he figures. "Server" should be understood in a >og,cal '"'^^^ ^X 
computer system con,a,„ing ,he da,a and running .he apphcahon and a.e motor. I 
may actaall be cnbodied m various machines - e. g. a separaie maehme fo 
Zaimng ,he da,a - or in a single compu.er. Requests and responses are no. 
etrentative of url requests and hh„, responses, bu. arc merely representaUve of «,e 
flow of messages to and f.om U,e server. "Requests" a. apphed .o the serv r by «, 
user machine or process; "responses" are received /^'^ 
machine or process. In the figures, data 56 is represented, for the sake of s,mpl c„y 
ZL *e sLver process; however, one could also consider that *c data ,s no. part 
of the server process. This is irrelevant as regards ,he opera„on of ,hc '-entton. 

The examples of figures 3 and 4 only show two client processes for .he sake ot 
simplicity; .he system may comprise more clien. processes, of various or smular 
™ s. ,m lcmen.a.io„ is no. d.scussed ,n de.ai, in figures 3-5. Indeed, r^any d.fferen 
lt.ons may be used for embodymg .he processes of .he ^^^'^ S'™'";;^ 
implemen.a.ion of U,e Unks be.ween .he various processes may be very d.fferen. h, 
the cxanrples of figure 5. Urics 62 and 96 could be carried over an httrane, or 
network. Applicat.on processes 80 and 82 could be running on the same machme. 
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Client processes could be running on distant terminals connected to the machine. The 
motor may be sold as a separate product, or as a part of a complete system. 
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CLAIMS 

L A computer system for allowing at least two client processes (52, 54, 68, 76, 
78) to access data (56) tlirough a server process (50) comprising an application (58) 
5 and a motor (60), wherein 

- the motor (60) is adapted to receive requests in a first language from one of client 
processes (52) and issue responses in the first language to said one of client 
processes, 

- the motor (60) is adapted to communicate with the application (58) in a second 
10 language distinct from the first language, the second language being an object- 
oriented language, with objects having properties and associated with events; 

- the application (58) is adapted to instantiate objects, to evaluate properties of 
instantiated objects based on data (56) and to react to events; 

and wherein 

15 - the motor (60) is adapted to issue responses in the first language to said one of 
client processes (52) according to the objects instantiated by the application and to 
their properties; 

- the motor (60) is adapted to provide updated properties and events to the 
application (58) in the second language according to requests received in the first 

20 language from said one of client processes (52). 

2. The system of claim 1, wherein 

- the motor (60) is further adapted to receive requests in the first language from 
another client process (54) and issue responses in the first language to said another 
client process (54), 

25 - the motor (60) is adapted to issue responses in the first language to said another 

client process (54) according to the objects instantiated by the application (58) and to 
their properties; 

- the motor (60) is adapted to provide updated properties and events to the 
application (58) in the second language according to requests received in the first 

30 language from said another client process (54). 

3. The system of claim 1 or 2, wherein 

- the motor (60) is further adapted to receive requests in a third language from 
another client process (68) and issue responses in the third language to said another 
client process (68), the third language being different from the first language and 

35 distinct from the second language; 

- the motor (60) is adapted to issue responses in the third language to said another 



R VBrcvelsWOSOOxZOSSgEP doc - 20/03**03 - 10 03 - KV14 



14 



client process (68) according to the objects instantiated by the application (58) and to 
their properties; 

- the motor (60) is adapted to provide updated properties and events to the 
application (58) in the second language according to requests received in the third 

5 language from said another client process (68). 

4. The system of claim 3, wherein the motor is provided with a first renderer (72) 
for communicating with said client process (52, 54) in said first language and with a 
second renderer (74) for communicating with said another client process (68) in said 
third language. 

10 5. The system of one of claims 1 to 4, wherein a client process (76, 78) 

communicates with the motor (60) of the server process (50) through an application 
process (80, 82), said application process comprising : 

- a second motor (84, 86) adapted to communicate with the client process (76, 78); 

- a second application (88, 90) adapted to communicate with the second motor (84, 
15 86); and 

- a chent interface (92, 94) adapted to communicate with the motor (60) in the first 
language and adapted to communicate with the second application (88, 90) and / or 
with the second motor (84, 86). 

6. The system of one of claims 1 to 5, wherein the first language includes html. 

20 7. A motor for serving clients processes (52, 54, 68, 76, 78) and allow the clients 
processes to access to data (56) managed by an application (58), the motor (60) 
comprising 

- a first renderer (72) adapted to receive requests from a client process in a first 
language and to issue responses in the first language; 

25 - a second renderer (74) adapted to receive requests from a client process in a third 
language and to issue responses in the third language, the third language being 
different from the first language; 

- an application interface (75) adapted to issue and receive messages in a second 
language, distinct from the first language and from the third language, the second 

30 language being an object-oriented language, with objects having properties and 
associated with events; 

wherein the motor (60) is adapted to issue responses in the first language through the 
first renderer (72) and responses in the third language through the second renderer 
(74) according to the objects and properties contained in the messages received on 
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the application interface (75); 

and wherein the motor (60) is adapted to issue through the application interface 
messages with updated properties and events according to requests received by the 
first and second renders (72, 74). 

8. The motor of claims 7, wherein the first language includes html. 
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ABSTRACT 

A computer system allows client processes (52, 54) to access data (56) through 
a server process (50). The server process contains an application (58) and a motor 
5 (60). The motor (60) receives requests in a first language from one of the client 
processes (52, 54) and issues responses in the first language to the client process. The 
motor (60) communicates with the application (58) in a second language distinct 
from the first language, the second language being an object-oriented language. In 
the second language, objects have properties and associated with events. The 

10 application (58) instantiates objects, evaluates properties of instantiated objects based 
on data (56) and reacts to events. The motor (60) issues responses in the first 
language to the client process (52) according to the objects instantiated by the 
application and to their properties; the motor also provides updated properties and 
events to the application (58) in the second language according to requests received 

15 in the first language from the client process (52). 

Thus, all client processes may access the data contemporaneously and share the 
data. Since the second language is distinct from the first language, the application 
may be used for various types of client processes, without being adapted. 

20 Figure 3 
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